Accept valid XML documents the token scan wrongly rejected - #175

Follow-up to #173. The root-element scan held the SAX-parity line too tightly in three places, rejecting documents a namespace-aware SAX parser accepts — safe-direction misses, but real gaps in the advertised parity, confirmed against OpenJDK 17's namespace-aware SAX parser:

Leading zeros in character references. The CharRef grammar has no digit cap, so 	 is legal. Digit runs are now unbounded in the scanner and bounded lexically — at most seven significant decimal digits or six hex, covering every code point through U+10FFFF — before conversion, so an unbounded digit run is never converted to an integer. All zeros denote #x0, still rejected.

PI targets and entity names use the full XML Name grammar. Namespace processing claims the colon in QNames and prefixes only; in a PI target or entity name it is an ordinary name character, so <?p:x?> and a DTD-covered &p:x; are valid. A new XML_NAME grammar (the NCName classes plus colon) is routed through skip_processing_instruction and valid_references?; QName parts and xmlns: prefixes stay NCName, and the reserved-xml-target check is untouched.

Legacy multibyte encodings are transcoded before scanning. Shift_JIS ソ is 83 5C — its trail byte is an ASCII backslash — so the raw byte scanner stopped mid-character inside names, attribute values, and DOCTYPE subsets. Documents declaring any encoding other than UTF-8 are now replace-transcoded to UTF-8 up front; a U+FFFD in the consumed prefix (through the end of the root start-tag) marks input the parser would reject, while replacements past the root — trailing garbage, a character split by MAX_SCAN — are never examined, preserving the pinned "invalid bytes after the root are harmless" boundary. One deviation from the narrow fix: declared US-ASCII also takes the transcode path rather than staying raw, which is behavior-identical (ASCII transcodes 1:1; high bytes become U+FFFD and reject exactly as the old valid_encoding? check did; US-ASCII cannot encode a genuine U+FFFD) and leaves the raw path purely UTF-8. The rare charset that can encode U+FFFD itself, like GB18030, only forfeits a refinement — noted in a comment.

With every scanned document UTF-8, valid_name? no longer threads the document encoding and valid_text? takes a text mode instead.

Probes cover each gap in both directions — the valid documents now refine, and the invalid neighbors (all-zero scalars, oversized references, undeclared &p:x;, bytes invalid in the declared encoding, US-ASCII high bytes) still hold the generic type — plus the boundary pins: invalid bytes stay fatal before the root and harmless after it, including a multibyte character split exactly at the scan limit. Full suite: 664 runs, 1684 assertions, 0 failures.